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Abstract.  Systems  thinking  is  commonly  accepted  as  the  backbone  of  a  successful  systems 
engineering  approach.  As  such,  the  Body  of  Knowledge  and  Curriculum  to  Advance 
Systems  Engineering  (BKCASE)  team  chose  to  leverage  a  systems  thinking  based  tool, 
called  Systemitool,  to  describe  our  project  to  the  vast  audience  that  would  potentially  become 
involved  directly  or  indirectly  in  the  success  of  the  project.  This  paper  describes  the  process 
and  steps  used  by  the  authors  and  the  BKCASE  team  to  develop  the  project’s  systemic 
diagram,  or  Systemigram™,  and  the  story  behind  the  project,  the  products,  and  the  vision  of 
the  BKCASE  project.  The  goal  of  the  paper  is  to  provide  guidance  so  that  readers  can 
leverage  the  lessons  learned  from  this  effort  to  successfully  develop  their  own  project 
definitions  and  stories. 


Introduction 

In  the  development  of  a  competency  framework  for  Systems  Engineering  (SE),  the 
International  Council  for  Systems  Engineering  (INCOSE)  includes  systems  thinking  as  one 
of  three  main  categories  (the  other  two  being  holistic  life  cycle  view  and  systems  engineering 
management)  of  the  framework.  INCOSE’ s  systems  thinking  category  includes  three 
competencies  that  the  team  believes  a  systems  engineer  should  possess:  1)  an  understanding 
of  general  systems  concepts,  2)  an  understanding  of  the  role  of  the  system  within  the  larger 
system  of  which  it  is  inevitably  a  part,  and  3)  an  understanding  of  the  system  context  within 
the  larger  enterprise  and  technological  contexts.  (INCOSE  UK,  2006)  As  part  of  her  PhD 
dissertation  work.  Dr.  Heidi  E.  Davidz  (2006)  found  that  “the  primary  mechanisms  that 
enable  systems  thinking  development  include  experiential  learning,  various  individual 
characteristics,  and  a  supporting  environment.”  (Davidz,  p.  5)  One  way  to  promote  systems 
thinking  is  in  the  successful  demonstration  of  the  use  of  systems  thinking.  This  paper 
describes  the  phases  used  to  apply  a  systems  thinking  methodology,  through  the  use  of  the 
Systemitool,  to  the  definition  of  the  Body  of  Knowledge  and  Curriculum  to  Advance  Systems 
Engineering  (BKCASE)  project. 
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Background 

As  described  in  Squires  (2009),  BKCASE  is  a  three-year  effort  to  produce  two  version  1.0 
products:  a  Systems  Engineering  Body  of  Knowledge  (SE  BoK)  and  a  Graduate  Reference 
Curriculum  in  System  Engineering  (GRCSE,  pronounced  “Gracie”).  The  project  was  kicked 
off  in  September  2009  by  the  Stevens  Institute  of  Technology,  together  with  the  Naval 
Postgraduate  School,  and  with  significant  funding  and  support  from  the  U.S.  Department  of 
Defense.  The  project  is  endorsed  by  the  INCOSE  Board  of  Directors  and  supported  by  the 
IEEE  Systems  Council  and  IEEE  Computer  Society.  The  BKCASE  team  includes  invited 
authors  and  volunteer  reviewers  from  around  the  world  and  has  representation  from 
government,  industry  and  academia.  Once  fully  staffed,  the  team  will  have  thirty  to  forty 
authors  and  several  hundred  reviewers.  The  project  charter  for  BKCASE  is  provided  in 
Appendix  A,  and  the  project  is  further  addressed  through  the  Systemigrams™  (*See 
endnotes),  reviewed  throughout  this  paper.  Additional  information  can  also  be  found  on  the 
project  website:  www .  bkcase  .  org.  Some  of  the  challenging  areas  that  are  being  addressed 
by  the  project  team  are  described  in  the  white  paper  in  Appendix  B.  These  challenges 
include  coming  to  consensus  on  the  boundary  or  scope  of  systems  engineering,  defining  the 
approach  or  framework  for  the  SE  BoK  and  GRCSE  and  dealing  with  diverse  terminology 
across  various  disciplines  and  domains  that  use  systems  engineering  (even  though  they  may 
call  systems  engineering  by  another  name). 

Due  to  the  challenging  nature  of  the  BKCASE  project,  communicating  the  project  intent  and 
strategy  across  the  broad  audience  that  will  be  potentially  be  participating  in  the  project  is  an 
important  first  step.  According  to  John  Boardman  Associates  (JBA),  the  Systemitool  is 
designed  to  “Transfer  understanding  -  the  tool  includes  presentation  facilities,  while  the 
intuitive  mode  of  representation  makes  your  diagrams  swiftly  comprehensible.”  (JBA,  1999) 
Blair  (2007)  used  Systemitool  to  develop  a  Systemigram™-based  story  that  demonstrated  the 
strategic  intent  of  U.K  Ministry  of  Defense  policy  makers  in  the  development  of  network 
enabled  capability.  Systemigrams™  created  from  Systemitool  were  used  in  Mansouri  (2009) 
as  an  enabler  for  shared  understanding  of  Maritime  Transportation  System  of  Systems 
stakeholder  perspectives,  needs  and  strategies.  Sivadasan  (2009)  used  Systemitool  to  create 
Systemigrams™  to  demonstrate  a  systems  perspective  of  the  issue  of  increasing  plagiarism  in 
the  academic  community.  An  initial  set  of  rules  for  Systemigram  development  can  be  found 
in  Blair  (2007)  and  Sivadasan  (2009).  Many  Systemigram  examples  and  a  more  thorough 
discussion  of  systems  thinking  can  be  found  in  Boardman  (2008).  Systemitool  was  chosen 
by  the  BKCASE  team  to  pictorially  demonstrate  the  strategic  intent,  value  proposition,  and 
objectives  of  the  project  and  to  tell  the  BKCASE  story;  and  the  process  that  was  used  is 
explained  in  the  body  of  this  paper. 


The  Process 

The  authors  and  BKCASE  team  leveraged  the  following  phases  and  guidelines  in  the 
development  of  the  BKCASE  Systemigram. 

Phase  I.  Create  an  initial  diagram  from  established  prose.  The  initial  project  Systemigram 
shown  in  Eigure  1  was  created  using  the  Project  Charter  shown  in  Appendix  A.  This  project 
charter  was  originally  developed  by  the  core  BKCASE  team  during  their  initial  project 
kickoff  meeting  and  documented  in  final  form  in  the  week  following  the  kickoff. 

In  the  initial  Systemigram,  the  project  vision  was  used  for  the  mainstay  of  the  system  story. 
This  mainstay  is  shown  from  the  top  left  hand  bubble,  BKCASE,  across  the  top  of  the 
diagram  down  the  right  hand  side  to  the  lower  right  hand  bubble,  SE  Community.  The 
remainder  of  the  diagram  was  fashioned  from  the  objectives,  project  strategy  and  value 


propositions  and  characteristics  of  the  two  main  products  SE  BoK  and  GRCSE,  as  described 
in  the  Project  Charter  in  Appendix  A.  The  goal  was  to  provide  a  diagram  of  the  entire  project 
in  one  page,  focusing  on  the  main  components  and  relationships  that  were  critical  to  a 
successful  projeet.  This  initial  Systemigram  was  informally  presented  to  the  BKCASE  team; 
and  team  members  provided  feedback  that  was  used  to  eompare  to  the  rules  of  Systemigram 
development  in  Phase  II. 


Systemigram 


Figure  1 .  Translating  the  Project  Charter  into  an  Initial  Systemigram 

Phase  II.  Compare  the  resulting  diagram  to  the  rules  of  Systemigram  development  and 
update  accordingly.  The  rules  for  creating  a  Systemigram  are  based  on  extensive  research 
and  the  following  guidelines: 

rules  should  provide  value,  not  constraints 

rules  should  be  based  on  proven  research  methods 

rules  should  support  intelleetual  flexibility  of  the  modeler 

In  our  ease,  the  Systemigram  author  (Squires)  had  access  to  a  Systemigram  expert  (Sauser) 
with  whieh  to  review  the  diagram.  The  established  rules  that  eame  into  play  and  how  they 
were  applied  were  as  follows: 

The  upper  left  hand  eorner  of  the  diagram  starts  with  the  system  being  described.  In 

our  ease,  we  confirmed  this  was  BKCASE  (pronouneed  ‘bookease’),  as  shown. 

The  lower  right  hand  node  and  the  mainstay  (bolded)  should  represent  the  end 

purpose  of  the  system.  SE  Community,  shown  in  the  lower  right  hand  corner  as  part  of 
the  mainstay,  was  not  in  itself  the  end  purpose.  While  the  SE  Community  is  an 
important  eomponent  of  the  story  and  part  of  the  vision  of  the  projeet,  this  node  was 
better  represented  as  a  critieal  node  in  the  ‘eenter’  of  the  system,  rather  than  as  the 
purpose  node. 

A  relationship  should  not  end  at  a  node  in  the  ‘middle’  of  the  diagram.  Eor  example. 


see:  The  ‘Fuzzy’  Boundary  of  Systems  Engineering  node.  There  were  several  reasons 
that  a  relationship  might  end  in  ‘random’  node  like  this.  First,  the  node  may  not  be 
needed.  Second,  there  may  be  a  missing  relationship  coming  from  the  node.  Third, 
the  node  itself  may  need  to  be  corrected  or  the  diagram  in  this  area  revamped. 

Relationships  can  be  phrases,  that  is,  nodes  should  not  be  defined  simply  because  a 

noun  is  involved.  For  example,  see:  guides  the  development  of  shown  in  Figure  1  as 
three  elements  in  the  diagram:  a  relationship,  a  node,  and  a  relationship.  These  three 
elements  could  be  better  shown  as  one  relationship  (no  nodes  needed)  between  the 
two  nodes  GRCSE  and  Graduate  Programs  in  SE.  The  point  is  that  verb  or 
prepositional  phrases  are  common  and  desired  as  part  of  a  Systemigram  and  the  noun 
parts  of  a  phrase  do  not  necessarily  need  to  be  nodes  in  the  diagram;  they  can  remain 
part  of  the  phrase  itself,  as  appropriate. 

Connection  nodes,  or  any  node  that  has  multiple  nodes  inside,  is  used  to  collect  nodes 

that  belong  to  one  specific  group.  In  Figure  1,  for  example,  the  SE  Community  node 
contained  elements  that  did  not  appear  to  be  part  of  the  community.  In  fact,  a 
community  in  the  sense  that  it  was  intended  for  this  diagram,  consists  of  collections  of 
people  rather  than  collections  of  items. 

Systems  should  only  be  shown  in  one  place.  The  SE  Graduate  Programs  shown  in 
the  SE  Community  bubble  is  the  same  element  as  the  Graduate  Programs  in  SE 
shown  as  a  collection  node  in  Figure  1 . 


These  discrepancies  would  need  to  be  addressed  in  the  next  version  of  the  Systemigram;  the 
new  diagram  that  resulted  from  this  phase  of  the  process  is  shown  in  Figure  2. 


Figure  2.  The  First  Formal  Version  of  the  Systemigram 
In  this  version,  the  mainstay  or  purpose  is  shown  along  a  diagonal  through  the  diagram  from 


BKCASE,  through  the  SE  Community,  to  The  ‘Go  To’  SE  Reference  products.  The 
Professional  Societies  became  part  of  the  SE  Community  where  they  belonged  along  with 
Government,  Industry  and  Academia.  Artifacts  previously  shown  as  part  of  the  SE 
Community  were  segregated  from  that  connection  node.  Duplicate  systems  and  ‘hanging’ 
nodes  were  eliminated;  and  superfluous  nodes  become  part  of  relationship  phrases.  This  was 
the  first  official  version  of  the  project  Systemigram  formally  presented  to  the  core  team,  as 
outlined  in  Phase  III. 


Phase  III.  Present  the  Systemigram  to  the  core  project  team  and  reach  consensus.  This 
phase  of  the  task  can  go  through  several  iterations  before  finally  coming  to  a  consensus. 
Initially,  the  core  team  struggled  with  Figure  2  for  several  reasons.  First,  the  end  node  at  the 
lower  right  hand  comer  acted  like  a  sink;  arrows  only  went  into  the  node,  and  nothing  was 
shown  as  coming  out.  When  the  author  described  the  intent  to  the  team,  it  became  clear  that 
the  BKCASE  products  were  duplicated.  Products  were  essentially  being  shown  in  both  the 
upper  left  hand  corner  bubble,  as  well  as  the  lower  right  hand  corner  bubble.  Relationships 
were  primarily  sourced  from  the  upper  right  bubble  and  all  the  relationships  were  received 
into  the  lower  right  hand  bubble.  This  did  not  accurately  portray  the  project  in  the  minds  of 
the  core  team  and  more  work  was  needed.  The  final  result  is  shown  in  Figure  3. 


Figure  3.  The  Final  BKCASE  Team  Version  of  the  Project  Systemigram 


Ultimately,  the  BKCASE  products  were  shown  in  the  bottom  right  hand  bubble  as  the 
outcome  and  main  purpose  of  the  project.  SE  Knowledge  was  moved  out  of  this  bubble  and 
into  the  main  part  of  the  Systemigram.  Eurther  detail  was  added  to  the  SE  Knowledge  bubble 
as  a  result  of  feedback  from  and  initial  meeting  with  the  core  team  and  nearly  two-dozen 
future  authors  on  the  project.  The  Systemigram  author  also  decided  to  keep  the  SE  BoK 
product  nodes  and  relationships  above  the  diagonal  and  the  GRCSE  product  nodes  and 
relationships  below  the  diagonal.  This  required  moving  the  SE  Certification  Programs 
connection  node  from  the  bottom  of  the  diagram  and  under  the  diagonal,  to  the  top  of  the 


diagram  and  above  the  diagonal.  This  decision  helped  streamline  the  project  story  developed 
in  Phase  IV. 

The  final  Systemigram  can  become  quite  complex  and  overwhelming  to  absorb  all  at  once. 
Once  the  team  agrees  on  the  project  diagram;  it  is  time  to  create  the  project  story.  The  process 
for  creating  the  story  is  outlined  in  Phase  IV. 

Phase  IV.  Create  the  project  story.  Once  the  project  diagram  is  to  a  level  that  the  core 
project  team  is  satisfied  of  its  accuracy  and  effectiveness  in  portraying  the  project;  then  it  is 
appropriate  to  create  the  project  story.  A  mature  Systemigram  can  be  ‘read’  such  that  the 
nodes  and  relationships  tell  a  story.  Creating  the  story  earlier  than  this  phase  may  result  in 
significant  rework.  The  project  story  starts  with  the  mainstay  or  purpose  of  the  project,  and 
then  each  of  the  major  sections  of  the  project  are  shown  and  explained  in  isolated  diagrams 
that  together  form  the  whole  of  the  Systemigram.  For  this  project,  the  story  can  be  heard  and 
seen  in  detailed  by  referring  to  the  project  website:  www .  bkcase  .  org.  The  BKCASE  story 
is  comprised  of  three  main  sections:  the  mainstay,  the  Systems  Engineering  Body  of 
Knowledge  (SE  BoK),  and  the  Graduate  Reference  Curriculum  for  Systems  Engineering 
(GRCSE).  The  story  of  BKCASE  starts  with  Eigure  4,  the  mainstay  of  the  Systemigram. 


As  an  example  of  the  BKCASE  story,  referring  to  Eigure  4,  one  can  read  the  Systemigram  as 
follows:  “The  BKCASE  project  is  supported  by  SE  experts  in  the  SE  Community  that 
together  create  BKCASE  products  (SE  BoK  and  GRCSE)  for  use  by  that  same  SE 
Community  that  shapes  and  endorses  the  BKCASE  project.”  This  completes  the  first  loop  of 
the  BKCASE  story.  In  addition,  from  the  same  Eigure  4,  one  can  see  that  another  goal  for  the 
project  is  that  the  Professional  Societies  will  maintain  the  BKCASE  Products  once  the  project 
is  completed  after  the  three-year  period.  The  second  part  of  the  story,  as  shown  in  Eigure  5  in 
completed  form,  describes  the  SE  BoK  product  and  how  that  product  will  be  created  and 
applied  to  SE  Workforce  Development  Initiatives,  SE  Competency  Models,  and  SE 


Certification  Programs.  The  applicable  parts  of  the  Systemigram  are  shown  to  complete  that 
part  of  the  story.  The  third  and  final  part  of  the  BKCASE  story  is  shown  in  completed  form  in 
Figure  6.  This  part  of  the  story  addresses  the  GRCSE  product  and  shows  how  that  product 
will  be  applied  to  the  development  of  Entrance  Expectations,  Defined  Student  Outcomes, 
Curriculum  Architecture,  and  Curriculum  Content  of  Graduate  Programs  in  SE. 


Figure  5.  The  Systems  Engineering  Body  of  Knowledge  (SE  BoK) 


Figure  6.  Graduate  Reference  Curriculum  for  Systems  Engineering  (GRCSE) 


Lessons  Learned 


The  Systemigram  created  directly  from  the  prose  was  confusing  even  with  the  guidance  and 
support  of  the  Systemitool.  One  could  see  the  elements  of  the  project  but  the  Systemigram 
did  not  tell  the  complete  story.  By  going  through  the  Systemigram  rules  and  leveraging  a 
Systemigram  expert,  we  advanced  the  diagram  to  the  next  level  and  the  diagram  was 
effectively  reviewed  and  critiqued  by  the  project  team  and  improved  further. 

Another  lessons  learned  is  that  understanding  all  the  phases  of  the  Systemigram  development 
process  up  front  can  help  in  making  the  right  decisions  in  the  development  of  the  diagram 
earlier  in  the  cycle.  For  example,  as  previously  mentioned,  because  there  are  two  main 
products  for  this  project,  it  helped  tremendously  when  it  came  time  to  tell  the  story,  that  the 
nodes  and  the  relationships  for  each  product  were  nicely  divided  above  and  below  the  main 
diagonal  of  the  project  mainstay. 

The  most  important  lesson  learned  pertaining  to  the  use  of  the  Systemitool  to  describe  a 
project,  was  our  team’s  decision  to  adopt  the  approach  that  the  top  left  hand  bubble 
represented  the  project  and  relationships  associated  with  project  management  and  support, 
and  the  bottom  right  hand  bubble  represented  the  products  to  be  produced  or  outputs  of  the 
project,  and  the  corresponding  relationships.  This  approach  simplified  the  development  of  the 
Systemigram  and  made  a  significant  difference  to  our  team’s  understanding  of  the 
Systemigram  and  its  message.  Following  this  guideline  may  be  of  general  benefit  when  using 
the  Systemitool  to  define  a  project.  Please  note  that  when  using  this  approach,  for  a  service- 
oriented  project,  the  bottom  right  hand  bubble  would  represent  the  services  provided.  Also, 
since  a  Systemigram  is  typically  ‘read’  from  the  upper  left  hand  corner  and  many  different 
pathways  lead  to  the  lower  right  hand  comer,  we  found  it  was  more  intuitive  to  expand  the 
reading  of  the  Systemigram  to  create  loops  from  the  project  in  the  upper  right  hand  corner,  to 
the  products  in  the  lower  right  hand  corner,  and  back  again. 

As  far  as  the  actual  tool  used  to  create  the  Systemigram,  one  downside  of  the  Systemitool 
was  the  manual  nature  of  creating  the  actual  diagrams;  lines  and  connection  points  had  to  be 
constantly  readjusted  and  it  was  sometimes  difficult  or  impossible  to  adjust  the  lines  as 
desired.  The  tool  currently  only  runs  on  a  Windows  operating  system,  and  there  is  only  the 
most  basic  help  provided  in  the  Help  menu.  However,  the  tool  provided  a  faster  method  than 
drawing  the  diagram  using  a  typical  drawing  tool  and  the  tool  includes  the  ability  to  create  a 
story  showing  only  those  parts  of  the  Systemigram  provided  from  one  slide  to  the  next. 
However,  the  slides  are  not  compatible  with  PowerPoint;  although  they  can  be  exported  into 
a  pdf  format  and  then  converted  to  common  jpeg  image  files  that  can  then  be  inserted  into 
PowerPoint  slides. 

One  overall  lesson  learned  from  the  experience  is  that  one  should  expect  to  go  through 
several  major  revisions  of  the  Systemigram  as  part  of  a  typical  and  successful  process.  Also, 
phase  III  and  IV  may  need  to  be  repeated,  as  feasible,  based  on  additional  feedback  or 
findings  during  the  project  development  cycle. 

Summary 

Creating  the  Systemigram  allowed  the  team  to  explain  the  BKCASE  project  in  a  way  that 
was  interesting,  memorable,  and  captivating.  For  example,  one  new  member  of  the  team 
mentioned  that  the  BKCASE  story  was  pleasurable  to  hear  and  that  they  really  had  not 
understood  the  intent  of  the  project  until  they  were  presented  the  Systemigram  story. 
Systemitool  is  an  extremely  basic  drawing  tool  that  allows  one  to  apply  systems  thinking  to 
develop  a  visually  pleasing  and  intuitively  comprehensible  description  of  a  system. 
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Appendix  A:  BKCASE  Project  Charter 

Please  note:  This  original  BKCASE  project  was  developed  as  a  joint  ejfort  by  the  first  five 
members  of  the  core  BKCASE  team  mentioned  in  the  Acknowledgements  of  this  paper.  The 
charter  is  dynamic  and  will  evolve  with  the  project. 

Vision:  “Systems  Engineering  competency  models,  certification  programs,  textbooks, 
graduate  programs,  and  related  workforce  development  initiatives  around  the  world  align 

with  BKCASE.” 

BKCASE  Objectives: 

1)  Create  a  SE  BoK  that  is  globally  recognized  by  the  SE  community  as  the  authoritative 
BoK  for  the  SE  discipline. 

2)  Create  a  graduate  reference  curriculum  for  SE  (GRCSE  -  pronounced  “Grade”)  that 
is  globally  recognized  by  the  SE  community  as  the  authoritative  guidance  for 
graduate  programs  in  SE. 

3)  Facilitate  the  global  alignment  of  related  workforce  development  initiatives  with  SE 
BoK  and  GRCSE. 

4)  Transfer  stewardship  of  SE  BoK  and  GRCSE  to  INCOSE  and  other  suitable 
professional  societies  after  BKCASE  releases  version  1.0  of  those  products. 

Value  Proposition  for  SE  BoK: 

•  There  is  no  authoritative  source  that  defines  and  organizes  the  knowledge  of  the  SE 
discipline,  including  its  methods,  processes,  practices,  and  tools.  The  resulting 
knowledge  gap  creates  unnecessary  inconsistency  and  confusion  in  competency 
models,  certification  programs,  educational  programs,  and  other  workforce 
development  initiatives  around  the  world.  SE  BOK  will  fill  that  gap,  becoming  the 
“go  to”  SE  reference. 

•  The  process  of  creating  the  SE  BoK  will  build  community  consensus  on  the 
boundaries  of  SE  -  what  is  in  and  what  is  out  of  SE,  although  those  boundaries  will 
likely  be  fuzzy  in  places. 

•  Having  a  common  way  to  refer  to  SE  knowledge  will  facilitate  communication  among 
systems  engineers.  Having  common  ways  to  identify  metadata  about  SE  knowledge 
will  facilitate  search  and  other  automated  actions  on  SE  knowledge. 

Value  Proposition  for  GRCSE: 

•  There  is  no  authoritative  source  to  guide  universities  in  establishing  the  outcomes 
graduating  students  should  achieve  with  a  master’s  degree  in  SE,  nor  on  reasonable 
entrance  expectations,  curriculum  architecture,  or  curriculum  content.  This  gap  in 
guidance  creates  unnecessary  inconsistency  in  student  proficiency  at  graduation. 


makes  it  harder  for  students  to  select  where  to  attend,  and  makes  it  harder  for 
employers  to  evaluate  prospective  new  graduates.  GRCSE  will  fill  that  gap, 
becoming  the  “go  to”  reference  to  develop,  modify,  and  evaluate  graduate  programs 
in  SE. 

Project  Strategy: 

1 .  Publish  incrementally /iteratively  with  SE  curriculum  reference  trailing  SE  BoK. 

2.  Throughout  the  project,  involve  professional  societies  to  facilitate  quality,  acceptance, 
and  their  eventual  role  as  stewards. 

3.  Build  early  consensus  and  maintain  it  throughout  the  lifetime  of  the  project. 

4.  Rely  on  and  include  academia,  industry,  and  government  for  authors  and  reviewers. 

5.  Extensively  leverage  volunteer  labor  for  both  authoring  and  review. 

6.  Rely  on  existing  source  material  wherever  possible  and  involve  principals  from 
efforts  that  created  source  material  wherever  possible. 

7.  Eeverage  the  processes  used  to  create  Graduate  Software  Engineering  2009 
(GSwE2009)  Curriculum  and  the  Naval  Postgraduate  School  Modeling  and 
Simulation  Acquisition  Curriculum. 

8.  Keep  completely  open  and  collaborative  at  a  global  level. 

9.  Hold  physical  workshops  every  3  months  to  synchronize  teams  and  build  team 
relationships  -  rely  on  virtual  meetings,  email,  and  other  collaboration  technology  at 
other  times. 

10.  Keep  the  team  focused  on  the  value  propositions  when  conflicts  arise. 

SE  BoK  Characteristics: 

1.  Provide  a  guide  to  “all”  SE  knowledge,  but  not  the  knowledge  itself,  offering 
“pointers”  to  knowledge  sources  in  SE 

2.  Be  authoritative  by  virtue  of  the  gravitas  of  the  authors,  endorsement  by  professional 
societies,  and  adoption  by  the  community 

3.  Include  a  taxonomy  of  the  knowledge  -  “all”  SE  knowledge  fits  within  the  SE  BoK 

4.  Define  the  boundaries  of  SE;  some  knowledge  will  be  unambiguously  included  in  SE; 
some  will  be  at  the  boundary  and  its  inclusion  will  be  fuzzy.  Euzzy  inclusion  is  an 
advantage  in  a  field  that  is  evolving  as  rapidly  as  SE. 

5.  Organize  (categorizes)  knowledge  for  fast  and  efficient  retrieval 

6.  Provide  a  baseline  of  SE  knowledge  at  a  given  time,  but  be  structured  to  facilitate 
evolution  as  new  knowledge  emerges  (additional  “pointers”)  and  the  field  itself 
changes  (changes  in  taxonomy) 

SE  Reference  Curriculum  Characteristics: 

1.  Provide  student  outcomes  on  graduation,  expectations  for  students  at  entrance, 
curriculum  architecture,  and  core  content  that  all  graduates  should  master  -  analogous 
to  GSwE2009. 

2.  Require  student  to  know  or  learn  about  the  application  of  SE  in  an  application  domain 
or  business  segment. 


3.  Include  companion  documents  to  GRCSE  that  facilitates  understanding  how  current 
graduate  programs  compare  to  GRCSE  guidelines  and  offers  advice  to  faculty  on  how 
to  adopt  GRCSE  guidelines. 

Team  Composition: 

1.  Stevens  Institute  of  Technology  will  lead  BKCASE.  Art  Pyster  will  be  the  Principal 
Investigator  and  editor  with  Alice  Squires  as  the  primary  researcher  supporting  the 
project.  Additional  faculty  and  staff  support  will  be  provided  as  required. 

2.  The  Naval  Postgraduate  School  co-leads  BKCASE.  David  Olwell  will  be  the  Co- 
Principal  Investigator  and  co-editor.  Stephanie  Pew  will  be  the  primary  research 
associate  supporting  the  project.  Additional  faculty  and  staff  support  will  be  provided 
as  required. 

3.  Volunteer  authors  will  work  an  average  of  about  1-2  days  per  month,  attend  quarterly 
workshops  and  participate  in  periodic  virtual  meetings.  Approximately  30-40  authors 
will  be  sought  representing  different  locales  and  business  segments.  Some  authors 
will  work  on  both  SE  BoK  and  GRCSE;  others  will  work  on  only  one  product. 

4.  Volunteer  reviewers  will  work  as  their  time  permits.  Several  hundred  reviewers  will 
be  sought,  representing  different  locales  and  business  segments.  Some  reviewers  will 
review  both  SE  BoK  and  GRCSE;  others  will  review  only  one  product. 

5.  INCOSE  will  provide  3  volunteer  authors  and  will  encourage  volunteer  reviewers  to 
participate  from  their  membership. 

6.  Don  Gelosh  will  be  the  technical  point  of  contact  for  the  U.S.  Department  of  Defense 
and  will  coordinate  its  additional  participation,  including  funding  support. 

7.  Participation  of  other  professional  societies,  such  as  the  IEEE,  will  be  sought. 

Draft  Schedule: 


This  schedule  is  notional  to  provide  general  insight  into  when  products  are  anticipated. 
The  real  schedule  will  emerge  after  the  author  team  is  assembled  and  work  begins. 


September  2009 
June  2010 
September  2010 
June  2011 
September  2011 
June  2012 
September  2012 


BKCASE  project  begins 
Version  0.25  SE  BoK 
Version  0.25  GRCSE 
Version  0.5  SE  BoK 
Version  0.5  GRCSE 
Version  1.0  SE  BoK 
Version  1.0  GRCSE 


Appendix  B:  BKCASE  White  Paper 

Please  note:  The  BKCASE  white  paper  represents  a  synopsis  of  a  series  of  discussions  of  the 
core  BKCASE  team. 

Preparing  for  the  First  BKCASE  Author  Workshop 

This  paper  assumes  you  are  already  familiar  with  the  Body  of  Knowledge  and  Curriculum  to 
Advance  Systems  Engineering  (BKCASE)  project  and  the  two  BKCASE  products,  a  robust 
Systems  Engineering  Body  of  Knowledge  (SE  BoK)  and  a  Graduate  Reference  Curriculum  in 


System  Engineering  (GRCSE,  pronounced  “Gracie”).  Eor  a  review  of  the  BKCASE  project, 
please  see  the  recording  and  presentation  with  notes,  at  www .  bkcase  .  org.  A  short  article 
on  the  project  will  also  be  in  the  December  version  of  the  INCOSE  Insight. 

The  purpose  of  this  paper  is  to  initiate  the  process  of  reflective  and  critical  thinking  that  must 
take  place  for  the  BKCASE  project  to  be  successful.  The  hope  is  that  members  of  the  author 
team  will  be  better  prepared  for  the  upcoming  author  workshop  after  reviewing  the  material 
provided  and  taking  time  over  the  next  few  weeks  to  consider  (think  about)  the  areas  and 
points  summarized  in  this  paper.  The  areas  selected  were  thought  to  be  the  more  challenging 
or  debatable  areas  in  systems  engineering  for  our  project.  The  areas  fall  into  three  broad 
categories:  the  boundary  or  scope,  the  development  approach,  and  terminology.  Within  each 
area  some  typical  issues  and  thought  points  are  listed.  The  issues  and  points  listed  within 
each  area  are  not  meant  to  bias  thinking  in  any  one  direction;  and  any  appearance  of  this  is 
unintentional.  Nor  are  the  areas,  issues  and  points  meant  to  be  all-inclusive.  Rather,  these 
are  intended  as  ‘thinking’  starters.  Suggestions  or  comments  are  welcome,  as  always. 

The  Systems  Engineering  Boundary 

Issues: 

•  There  is  no  globally  accepted  definition  of  systems  engineering. 

•  Systems  engineering  means  different  things  to  different  people. 

•  Systems  engineering  is  used  across  many  different  domains  in  different  and  possibly 
conflicting  ways. 

•  It  will  be  difficult  to  come  to  a  consensus  on  the  major  boundaries  of  the  discipline 
including  where  the  boundary  is  more  definite  versus  where  it  may  remain  ‘fuzzy’; 
that  is:  what’s  in,  what’s  out,  and  what’s  fuzzy. 

Thought  points: 

•  Where  do  we  start?  With  expected  outcomes  or  the  ideal  end  game?  With  a  clear 
definition  of  the  problem? 

•  How  do  we  address  systems  engineering  centric  versus  domain  centric  systems 
engineering  considerations? 

•  Where  do  systems  engineering  processes  versus  systems  engineering  artifacts  versus 
formulas  for  systems  engineering  fit  in? 

•  Should  we  address  the  standardization  of  a  problem  solving  framework  and 
identification  of  the  root  cause  as  part  of  the  scope? 

•  How  should  we  deal  with  different  types  of  systems  engineers  and  the  applicable 
workforce  requirements  and  employee  competency/skill  sets  when  defining  the 
boundary? 

•  Where  does  graduate  versus  undergraduate  versus  K-12  education  fit  in? 

The  Approach  for  Developing  the  SE  BoK  and  GRCSE 

Issues: 

•  It  will  be  difficult  to  come  to  a  consensus  on  the  best  approach;  furthermore,  the  best 
approach  may  be  different  for  each  of  the  BKCASE  products,  compounding  the  issue. 

•  The  BKCASE  products  must  accommodate  future  growth  that  is  not  known  or 
predictable  in  an  environment  that  is  constantly  changing. 


•  The  BKCASE  products  must  be  maintained  over  time  outside  of  the  current  funding 
structure. 

•  One  of  the  main  BKCASE  project  strategies  is  to  keep  the  project  open  and 
collaborative  at  a  global  level.  The  project  leverages  a  team  of  authors  some  of  which 
are  principals  on  efforts  that  created  source  material  and  a  subset  of  these  are 
proprietary;  we  need  to  ensure  the  BKCASE  products  will  be  non-proprietary  and 
open  at  all  times. 

•  We  have  to  succeed  where  others  have  not. 

Thought  points: 

•  What  has  been  done  before?  What  worked?  What  didn’t  work? 

•  What  is  a  robust  approach  that  allows  for  adaptability  -  changes  in  the  approach  as  we 
reach  consensus  on  the  various  aspects  -where  the  requirements  as  we  understand 
them  will  evolve  and  change?  Should  we  create  an  ‘Adaptive’  SE  BoK? 

•  How  can  the  approach  be  flexible  to  allow  for  a  variety  of  methods  for  everything 
from  development  to  implementation  to  search  to  addition  or  replacement? 

•  What  do  we  need  to  do  to  ensure  the  products  are  maintainable  in  the  long  term 
within  a  reasonable  cost  and  schedule  structure  and  still  meet  the  need  to  evolve  the 
content  so  that  the  content  remains  current,  accurate  and  complete? 

•  How  do  we  ensure  the  global,  open  nature  of  the  products  over  time? 

Systems  Engineering  Terminology 

Issues: 

•  There  exists  specific  albeit  different  terminology  used  by  each  domain  and/or 
industry. 

•  A  description  may  have  everything  to  do  with  systems  engineering  but  it  is  not  easily 
recognizable  as  systems  engineering  when  the  terminology  being  used  is  non¬ 
mainstream  or  unfamiliar. 

•  Confusion  and  misunderstanding  are  associated  with  “ _ (fill  in) _ systems” 

engineering  versus  “ _ (fill  in) _ ”  systems  engineering;  that  is,  with  the 

engineering  of  systems  within  a  domain  versus  systems  engineering  within  a  domain. 

Thought  points: 

•  Should  we  standardize  the  systems  engineering  terminology  to  be  accepted  and  used? 

•  Should  we  define  certain  aspects  of  the  terminology  and  recognize  that  other 
terminology  is  equally  acceptable  in  use? 

•  Should  we  define  a  body  of  terminology  as  standard  and  other  terminology  as 
tailorable  to  the  topic?  Or  domain? 

•  Should  we  allow  multiple  different  terminologies  to  be  used  for  the  same  thing, 
perhaps  providing  a  thesaurus  for  guidance? 

•  Should  we  include  a  ‘translator’  between  domains  as  part  of  a  definition  of  standard 
or  common  systems  engineering  terminology? 

A  list  of  main  BKCASE  references  has  been  provided  as  a  separate  attachment,  and  we  ask 

that  you  review  the  top  six  references,  noted  in  ‘red  font’  in  the  list  of  main  references,  prior 

to  the  workshop.  Most  of  the  references  are  available  through  public  urls  at  this  time  and 


these  are  provided  in  the  list.  For  those  references  that  are  not  publicly  available  a  url  that 
requires  a  password  is  provided  to  access  the  documentation. 

During  the  workshop,  perhaps  the  most  difficult  personal  challenge  will  be  to  keep  an  open 
mind  to  allow  the  group  to  build  consensus  for  the  greater  good  of  the  project.  It  is  many 
times  easier  to  identify  lack  of  an  open  mind  in  others  rather  than  oneself.  See  “An  Open 
Way:  10  Suggestions  to  Talking  and  Listening  that  are  Simple  but  Not  Easy”  on  page  3  of 
this  attachment  of  a  book  review  for  “Solving  Tough  Problems”  by  Adam  Kahane: 
WWW .  bkconnect  ion  .  com/stat  ic/solvingtoughPR .  pdf  for  some  interesting 
guidance  in  this  area. 

So  put  on  your  thinking  hats,  and  get  prepared  to  come  to  our  next  workshop  with  an  open 
mind  and  some  great  ideas!  See  you  there. 

References 

Blair,  C  D,  J  T  Boardman,  and  B  J  Sauser.  2007.  Communicating  strategic  intent  with 
Systemigrams:  Application  to  the  network-enabled  challenge.  Systems  Engineering  10  (4): 
309-322. 

Boardman,  J  and  B  Sauser.  2008.  Systems  Thinking:  Coping  with  21St  Century  Problems. 
Boca  Raton,  FL:  Taylor  &  Francis  /  CRC  Press. 

Davidz,  H  F.  2006.  Enabling  systems  thinking  to  accelerate  the  development  of  senior 
systems  engineers.  Submitted  to  the  Engineering  Systems  Division  in  partial  fulfillment  of 
the  requirements  for  the  degree  of  Doctor  of  Philosophy  in  Engineering  Systems  at  the 
Massachusetts  Institute  of  Technology.  Boston,  MA,  USA:  Massachusetts  Institute  of 
Technology. 

INCOSE  UK,  BAE  Systems,  EADS  Astrium,  General  Dynamics  United  Kingdom  Eimited, 
Eoughborough  University,  Thales,  Ultra  Electronics,  and  University  College  Eondon.  2006. 
Systems  Engineering  Competencies  Framework.  INCOSE  UK. 

John  Boardman  Associates  Etd.  1999.  Systemitool. 

http  :  / / WWW .  jba  .  net/ index  .  html# 63.  (accessed  November  29,  2009). 

Kahane,  A.  2004.  Solving  tough  problems:  An  open  way  of  talking.  Listening,  and  Creating 
New  Realities  (Berrett-Koehler:  Sean  Francisco). 

WWW .  bkconnect  ion  .  com/ static/ solvingtoughPR .  pdf  (accessed  November 
15,  2009). 

Mansouri,  M.,  B.  Sauser,  and  J.  Boardman.  2009.  Applications  of  systems  thinking  for 
resilience  study  in  maritime  transportation  system  of  systems.  In  IEEE  International  Systems 
Conference.  March  23-26,  2009,  Vancouver,  British  Columbia,  Canada. 

Sivadasan,  S.  and  B.  Sauser.  2009.  Understanding  plagiarism  using  boardman's  soft-systems 
methodology.  In  Proceedings  of  the  2009  American  Society  for  Engineering  Education 
(ASEE)  Annual  Conference  and  Exposition,  Austin,  TX,  June  14-17,  2009. 

Squires,  A.,  A.  Pyster,  D.  Olwell,  S.  Few,  and  D.  Gelosh.  2009.  Announcing  BKCASE:  Body 
of  knowledge  and  curriculum  to  advance  systems  engineering.  INCOSE  Insight  12  (4):  p  69- 
70. 

*Systemigram  is  a  registered  trademark  of  JTB  Associates. 


BIOGRAPHY 

Alice  Squires  is  a  PhD  candidate  and  faculty  in  Systems  Engineering  in  the  School  of 
Systems  and  Enterprises  at  Stevens  Institute  of  Technology  with  over  28  years  of  experience. 
After  completing  her  Electrical  Engineering  bachelor’s  degree  at  the  University  of  Maryland, 
she  served  as  a  technical  lead  for  IBM,  completed  her  MBA  from  George  Mason,  served  as  a 
senior  systems  engineering  manager  for  both  Eockheed  Martin  and  General  Dynamics  (GD). 
Next,  she  served  as  a  Senior  Systems  Engineer  consultant  to  Eockheed  Martin,  IBM,  and 
EDO  Ceramics,  for  ASSETT.  Alice  holds  INCOSE  CSEP,  CSEP-Acquisition  certifications. 

Art  Pyster  is  a  Distinguished  Research  Professor  in  the  School  of  Systems  and  Enterprises  at 
Stevens  Institute  of  Technology  and  the  Deputy  Executive  Director  of  the  Systems 
Engineering  Research  Center,  a  Department  of  Defense’s  University  Affiliated  Research 
Center.  Previously,  he  served  in  leadership  roles  for  SAIC,  the  Eederal  Aviation 
Administration,  the  Software  Productivity  Consortium,  Digital  Sound  Corporation  and  TRW. 
During  his  career.  Art  directed  the  creation  of  three  Capability  Maturity  Models,  oversaw 
more  than  $10  billion  in  investments  and  has  authored  many  papers  and  one  textbook  - 
Compiler  Design  and  Construction.  He  is  an  INCOSE  Eellow. 

Brian  Sauser  holds  a  B.S.  from  Texas  A&M  University,  M.S.  from  Rutgers,  The  State 
University  of  New  Jersey,  and  Ph.D.  from  Stevens  Institute  of  Technology.  He  is  an 
Assistant  Professor  in  the  School  of  Systems  and  Enterprises.  Before  joining  Stevens  in  2005, 
he  spent  over  12  years  working  in  government,  industry,  and  academia  as  a 
researcher/engineer  and  director  of  programs.  His  research  interests  are  in  theories,  tools,  and 
methods  for  bridging  the  gap  between  systems  engineering  and  project  management  for 
managing  complex  systems.  He  serves  as  Director  of  the  Systomics 
(http: //www.SystomicsLab.com)  and  Systems  Development  and  Maturity 
(http  :  /  / WWW .  SystemReadinessLevel .  com)  Eaboratories  at  Stevens. 

David.  H.  dwell  is  Professor  of  Systems  Engineering  at  the  Naval  Postgraduate  School, 
where  he  recently  completed  a  five-year  term  as  department  chair.  His  research  interests  are 
reliability  engineering  and  statistical  quality  control.  He  previously  was  on  the  faculty  of  the 
United  States  Military  Academy. 

Stephanie  Enck  is  a  research  assistant  at  the  Naval  Postgraduate  School’s  Systems 
Engineering  Department.  She  has  a  Bachelor  of  Science  in  Communication,  sales  and 
marketing  management  experience,  and  volunteered  to  assist  Army  families  for  several  years 
before  joining  the  SE  department  at  NPS.  Her  research  interests  and  project  coordination 
efforts  include  M&S  education,  project  management,  and  SE  education. 

Don  Gelosh  is  the  Deputy  Director  for  Workforce  Development  in  the  OSD  Directorate  of 
Systems  Engineering.  He  provides  expertise  in  workforce  development,  competency,  and 
knowledge  management  and  has  over  33  years  of  combined  experience  from  the  US  Air 
Eorce,  government,  industry,  and  academia.  Don  received  a  PhD  in  Electrical  Engineering 
from  the  University  of  Pittsburgh  in  1994,  a  MS  in  Computer  System  Design  from  the 
University  of  Houston  at  Clear  Eake  in  1989,  and  a  BS  in  Electrical  Engineering  from  the 
Ohio  State  University  in  1981.  He  also  holds  an  INCOSE  CSEP-Acquisition  certification. 

Jim  Anthony  is  a  Senior  System  Engineer  supporting  the  Department  of  Defense  Systems 
Engineering  Directorate.  He  has  27  years  engineering  experience  with  the  U.S.  Air  Eorce, 
U.S.  Navy,  Defense  Threat  Reduction  Agency,  and  DoD  Modeling  and  Simulation 
Coordination  Office.  He  is  “Qualified  in  Submarines”  and  a  retired  U.S.  Navy  Commander. 
He  has  a  B.S.  in  Chemical  Engineering,  Magna  cum  Laude,  (1981)  from  Christian  Brothers 
University  and  a  M.S.  in  Systems  Engineering  from  George  Mason  University  (2006). 


